LtU Forum, Site Discussion

Unix as programming language

It has been discussed recently somewhat in The new old..
and Revisiting AWK, but I am finding more and more treatments of Unix shell scripting (actually, not quite "shell scripting", but the combination of all of the Unix mini-languages) as a means to perform complex tasks usually reserved for real monolithic programming languages.

Here is an interesting (intro level) computational linguistics paper (original postscript) (verbatim pdf) about counting trigrams on a decent size corpus using just standard Unix utilities.

Type Refinements for Programming Languages

Type Refinements for Programming Languages is the web page for a graduate course at CMU. It is full to the brim of great papers about PL theory, including some things we talk about here, like Soft Type Systems, Dependent Types, and Polymorphic Type Inference.

G'Caml comes of age

G'Caml, which extends O'Caml with overloading, has been around since O'Caml 2.0something. It is now updated with its own source code (no more patching!) and some new features (generic primitives?) that I don't understand.

I think I remember seeing Simon Peyton-Jones predict somewhere that ML would grow type classes. Will G'Caml metastasize?

The Next Mainstream Programming Languages

I didn't see anyone post them yet, so here are the slides from Tim Sweeney's POPL talk entitled "The Next Mainstream Programming Languages: A Game Developer's Perspective". I know Tim and I aren't the only game developers who follow LtU, and I figure even non-game developers might find them quite interesting!

http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

What is a monad, why should I use it, and when is it appropriate?

What is a monad, why should I use it, and when is it appropriate?

Can anyone answer this in a post without showing code? And if possible, relate it to OO concepts like classes and delegates.

Is the .NET platform embracing quotation and macros?

If you read between the lines (even if you don't) in Don Syme's blog post (near the end) he talks about DLinq and the use of quotation, abstract syntax and stuff like that.

In the C# 3.0 spec the Expression trees (26.8) are slipped in right at the end with the promise of another specification to describe them.

Packaging Data And Methods

While studying OO at university, it was drilled into me that I should "package data with the methods that operate on that data".

In recent years I have come to wonder why so much emphasis is placed on this concept.

For example, most 3D Vector classes I have encountered look something like:

class 3DVector
{
private float X;
private float Y;
private float Z;

public 3DVector Normalize();
public 3DVector Add (3DVector other);
public float Dot (3DVector other);
... etc
}

This appears well organised.. Various methods that act on a 3D vector nicely packaged up together. I'm guessing most OO programmers would generally approach class design in this way.

But at the same time, its very hard for multiple vendors to add their own functionality to the class, they are forced to collaborate and merge their methods into the "current version".

In this instance, would it not be more sensible to have something like:

class 3DVector // Agreed, Never going to change
{
public float X;
public float Y;
public float Z;
}

---- Vendor (1)

3DVector Vendor1_3DVector_Normalize (3DVector v)
3DVector Vendor1_3DVector_Add (3DVector a, 3DVector b)
float Vendor1_3DVector_Dot (3DVector a, 3DVector b)

---- Vendor (2)

3DVector Vendor2_3DVector_Cross (3DVector a, 3DVector b)
float Vendor2_3DVector_Length (3DVector v)
3DVector Vendor2_3DVector_Dot (3DVector a, 3DVector b)

Then as a vendor, you are able to release new functions as and when you please.

As an application developer, you are free to pick and choose those functions that fit your requirements, or add your own.

The vendors would have to collaborate on the initial "Data Format" of a class, but once settled, an eco-system of functions would build up that operate on it.

I realise this is a simplistic example, and can see it would be hard to extend the idea to more complex objects with state. But I was curious whether there are any real-world OO systems that leverage this sort of thing, and how far they take it?

Everything Your Professor Failed to Tell You About Functional Programming

My Google Alert on Haskell tortured me with weeks of unrelated news about folks called Haskell, sports results from a college of the same name and local incidents from a town of the same name. Finally today I got a on-topic hit. Allow me to share it with you, it is here.

PS Is this is the proper way to submit some interesting link?

U, a small model


U is a small (< 1000 words) computational model:

http://urbit.sf.net/u.txt

U is different because it:

  • has no user-defined functions or lambda
  • has a built-in hyper-Turing operator
  • expects an unreliable packet network

I have to apologize for posting this weird beast with no real context. I'm working on higher layers that should make its purpose clearer, but they are not done, and we all hate hand-waving. Still, the U spec is self-contained, and it should be precise and readable. If anyone can look at it and maybe even find some gotchas, I'd be super grateful.

I'm especially curious about the follow operator. Are there any logical flaws in its definition, or ways it could be improved, generalized or tightened?

Also, if anyone knows of any other UDP-level functional languages, or anything else U reminds them of, I would of course be happy to hear it.


Thanks,
Curtis
(curtis dot yarvin, at gmail)

Weak vs. strong typing

So... how big can dynamically-typed systems get? Do static type systems really matter? I'd love to know the answer to this.

We have some big systems at Amazon, and most of them seem to use strong static typing; at least the ones I know about do. Is that a requirement, or could we just as well have done them in Perl, Ruby, Lisp, Smalltalk?

Read more about it here.

XML feed